<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>1.2.1-性能与可维护性的权衡</title>
</head>
<body>
    
</body>
    <script>
        /**
         * 声明式代码的更新性能消耗 = 找出差异的性能消耗 + 直接修改的性能消耗
         * - 如果我们能够最小化找出差异的性能消耗，
         *    就可以让声明式代码的性能无限接近命令式代码的性能
         * - 所谓的虚拟 DOM，就是为了最小化找出差异这一步的性能消耗而出现的
         * 
         * 采用虚拟 DOM 的更新技术的性能理论上不可能比原生 JavaScript 操作 DOM 更高
         * - 大部分情况下，我们很难写出绝对优化的命令式代码，
         *    尤其是当应用程序的规模很大的时候，
         *    即使你写出了极致优化的代码，也一定耗费了巨大的精力，
         *    这时的投入产出比其实并不高
         * 
         * innerHTML 和虚拟 DOM 在创建页面时的性能
         * - 无论是纯 JavaScript 层面的计算，还是 DOM 层面的计算，其实两者差距不大
         * - 从宏观的角度只看数量级上的差异。如果在同一个数量级，则认为没有差异
         * - 在创建页面的时候，都需要新建所有 DOM 元素
         * 
         * 更新页面时的性能
         * - 使用 innerHTML 更新页面的过程
         *  -- 重新构建 HTML 字符串，再重新设置 DOM 元素的 innerHTML 属性
         *  -- 重新设置innerHTML 属性就等价于销毁所有旧的 DOM 元素，再全量创建新的DOM 元素
         * - 虚拟 DOM 是如何更新页面的
         *  -- 需要重新创建JavaScript 对象（虚拟 DOM 树），然后比较新旧虚拟 DOM，找到变化的元素并更新它
         * 
         * 1. 在更新页面时，虚拟 DOM 在 JavaScript 层面的运算要比创建页面时多出一个 Diff 的性能消耗，
         *      然而它毕竟也是 JavaScript 层面的运算，所以不会产生数量级的差异
         * 2. DOM 层面的运算，可以发现虚拟 DOM 在更新页面时只会更新必要的元素，但innerHTML 需要全量更新。
         *      这时虚拟 DOM 的优势就体现出来了。
         * 3. 对于虚拟 DOM 来说，无论页面多大，都只会更新变化的内容，
         *      而对于 innerHTML 来说，页面越大，就意味着更新时的性能消耗越大
         * 
         * 
         * 总结 - 心智负担、可维护性和性能
         * 1. 原生 DOM 操作方法
         * - 要手动创建、删除、修改大量的 DOM 元素
         * - 它的性能是最高的
         * - 巨大的心智负担
         * - 可维护性也极差
         * 2. innerHTML 来说
         * - 有一定心智负担的
         * - 事件绑定之类的事情，我们还是要使用原生 JavaScript 来处理
         * - 模板很大，则其更新页面的性能最差
         * 3. 虚拟 DOM
         * - 心智负担小
         * - 可维护性强，性能虽然比不上极致优化的原生 JavaScript，
         *     但是在保证心智负担和可维护性的前提下相当不错
        */
    </script>
</html>